1. Field of Invention
The invention relates generally to methods and apparatuses for implementing name services in distributed object systems. More particularly, the invention relates to methods and apparatuses for implementing CORBA compliant name services.
2. Description of Relevant Art
Name services are often implemented within distributed object systems to enable distributed objects to be readily identified. One type of a distributed object system which uses name services includes a distributed object system that is defined under the Common Object Request Broker Architecture (CORBA) specification produced by OMG. Distributed object systems which use name services may be in the context of an. Object Request Broker (ORB) implemented under the CORBA specification from the OMG, Revision 2.0, Revision 2.1, Revision 2.2 and Revision 2.3, all of which are incorporated herein by reference in their entirety. Specifically, the xe2x80x9cCosNamingxe2x80x9d module of the CORBA Services specification, as specified in the CORBA specification from the OMG, may be used to implement name services. For purposes of this application, programs compliant with CORBA Revision 2.3, 2.2, and 2.1, by definition will be viewed as compliant with CORBA Revision 2.0. Unless otherwise specified, a generic reference to the CORBA Services specification will be presumed to be OMG""s CORBA Services Revision 2.0. The components of the CORBA Services specification detailed above which address name services will be referred to hereinafter as the CORBA CosNaming Specification.
A name service, which may be associated with a name server, is typically arranged such that, when provided with a name, the name service associates the name with xe2x80x9csomething,xe2x80x9d e.g., an object, an object reference, or a property. The association of the name with an object, for example, may either be transient or persistent. For a transient name service, the association between a name and an object generally disappears once the program which implements the name service terminates. Alternatively, for a persistent name service, the association between a name and an object is stored in a data file, and does not disappear once the program which implements the name service terminates. In general, the implementation of a name service often includes the implementation of a data structure such as a table (or hash table) to hold bindings between names and object references and, in some cases, properties. Such a data structure, in other words, may be used to associate names with object references, as well as properties. Such a data structure is maintained in a data store and accessed through a data store interface, where such data store may be persistent or transient.
Both U.S. Pat. No. 6,044,379 to Callsen, issued Mar. 28, 2000 for xe2x80x9cMethod and apparatus for efficiently implementing multiple storage mechanism for name services associated with a computer systemxe2x80x9d and U.S. Pat. No. 5,873,092 to Cheng, et al., issued Feb. 16, 1999 for xe2x80x9cInformation handling system, method, and article of manufacture including persistent, distributed object name services including shared propertiesxe2x80x9d address efforts to improve naming services and provide detailed background information known to those of skill in the art regarding the operations of naming services. Both of these patents are incorporated herein by reference.
A typical implementation of a name service includes a xe2x80x9cmainxe2x80x9d table. Although the main table may take on a variety of different configurations, the main table is typically a look-up table, or a list, which associates names in a name column of the main table with references in a reference column of the main table. References in the reference column identify, or reference, objects which are associated with names. By way of example, name xe2x80x9cXxe2x80x9d is associated with reference xe2x80x9cx.sub.pxe2x80x9d, which is a reference to a specific object. As such, reference xe2x80x9cx.sub.pxe2x80x9d is essentially an object reference which identifies the specific object. A reference is also referred to as an object reference or simply a reference, which in a CORBA compliant system is typically a relatively extensive IOR. The use of a name service enables a name, such as name xe2x80x9cXxe2x80x9d, to be remembered, instead of reference xe2x80x9cx.sub.pxe2x80x9d, when access to the specific object is desired. By using a name as an index into the main table to identify an object, the overhead, and, hence, the complexity associated with locating objects can be reduced.
A look-up table, which is included as a part of a name service, may either be transient or persistent. For a transient name service, local look-up tables, i.e., look-up tables which were created locally during a process, are temporarily stored in volatile memory, and are not stored into a file. As such, when a program which implements the local look-up tables terminates, the local look-up tables, in addition to information contained in local look-up tables, is destroyed. Alternatively, for a persistent name service, the local look-up tables are stored into files, as for example files on a non-volatile memory, such as a disk. Hence, data contained in look-up tables associated with a persistent name service is not destroyed when the program which implements the look-up tables is terminated.
A name may generally be expressed as an array of name components. In a CORBA compliant system, each of the name components comprises a pair of strings (the id string and the kind string). In other words, although a name may be expressed as xe2x80x9c/a/b/c/dxe2x80x9d (or even xe2x80x9cabcdxe2x80x9d), when a name is to be processed, e.g., bound or resolved, the name is typically processed as an array of components [a, b, c, d], and for illustrative purposes will be referred to in this fashion. When the name [a, b, c, d] is being xe2x80x9clooked up,xe2x80x9d or resolved, using a name service, the components of the name are looked up sequentially. The first component of the name, i.e., xe2x80x9ca,xe2x80x9d is resolved first, while the last component of the name, i.e., xe2x80x9cd,xe2x80x9d is resolved last. For example, a name service implementation may include multiple look-up tables which may be used to identify a reference to an object that is associated with and, hence, may be identified by name [a, b, c, d]. Such a name service implementation could include a main look-up table which is used to associate a reference xe2x80x9ca.sub.pxe2x80x9d with a first component xe2x80x9caxe2x80x9d of name [a, b, c, d].
Reference xe2x80x9ca.sub.pxe2x80x9d identifies a second look-up table in which a second component xe2x80x9cbxe2x80x9d of name [a, b, c, d] may be found. Second component xe2x80x9cbxe2x80x9d is associated with a reference xe2x80x9cb.sub.pxe2x80x9d which identifies a third look-up table. The third -look-up table is used to find a third component xe2x80x9ccxe2x80x9d of name [a, b, c, d], which is associated with a reference xe2x80x9cc.sub.pxe2x80x9d that references a final look-up table. In this example, the final look-up table is the last in a chain of look-up tables associated with name service implementation. However, as will be appreciated by those skilled in the art, the number of look-up tables associated with a name is often dependent upon the number of components in the name.
The final look-up table associates, e.g., binds, component xe2x80x9cdxe2x80x9d of name [a, b, c, d] with a reference xe2x80x9cO.sub.ptrxe2x80x9d. In other words, when name [a, b, c, d] is traversed until only component xe2x80x9cdxe2x80x9d remains, component xe2x80x9cdxe2x80x9d may then be bound to reference xe2x80x9cO.sub.ptrxe2x80x9d which references an object which is associated with the overall name xe2x80x9cabcd.xe2x80x9d When the name service stores look-up tables, either in volatile memory or in non-volatile memory, the four tables are all stored. As will be appreciated by those skilled in the art, typically, either all or none of tables are stored. When all tables are stored, by way of example, the first table is either temporarily stored in volatile memory, such that the first table is destroyed when the program that implements the name service implementation terminates, or the first table is written into a file on a disk. In other words, for a transient name service, the first table is stored in volatile memory, whereas for a persistent name service, the first table may be stored on a disk. By analogy, the other tables are stored in the same manner.
Some name services may also store properties in look-up tables. For example, the final look-up table may include references to a property table which contains a property that is associated with name [a, b, c, d]. A reference xe2x80x9cpropxe2x80x9d associated with name [a, b, c, d] may identify a property table which contains properties and may, in some instances, also include objects.
The data from the various look-up tables is stored in a data store or a group of data stores, which may be transient or persistent, as discussed above. Information or data is placed into and retrieved out of the data stores by a data store interface. To the extent the prior art addresses the use of persistent data stores to support name services, the prior art has focused on the use of relational databases as the primary vehicle for data storage.
In other areas of programming, alternative methods do exist to the use of relational databases as data stores. One alternative is the use of flat files. Another alternative is the use of directory services. One standardized method of implementing directory services, and data store interfaces to interact with directory services, is the use of the Lightweight Directory Access Protocol version 2, the specification of which is incorporated herein by reference in its entirety. Hereinafter, when discussing this specification, it may also be referred to as LDAP version 2. LDAP version 3 also may be used and its specification is also herein incorporated by reference. LDAP is used as a generic designation for interfaces and protocols compliant with a version of the Lightweight in Directory Access Protocol. For purposes of this application, by definition any server or interface which is compliant with LDAP version 3 would also be viewed as compliant with LDAP version 2. The converse is not necessarily correct.
The invention comprises methods and apparatus for implementing a name service. According to the present invention, a name service with:at least one storage mechanism may be implemented by creating a name service, preferably compliant with the CORBA CosNaming Specification, where the name service is arranged to store information in persistent storage. For the purposes of this application xe2x80x9cpersistent informationxe2x80x9d will be defined as information which either is stored in persistent storage or is to be stored in persistent storage. The storage mechanism comprises a directory service, preferably a directory service compliant with LDAP version 2, and is arranged to store the persistent information for the name service. The name service may be further implemented by creating a data store interface for interacting with the directory service, wherein such interaction comprises the use of protocol compliant with LDAP version 2.
From a different perspective, this aspect of the invention involves a name service within a computer system, the name service being arranged to store persistent information. The name service has at least one storage mechanism arranged to store the persistent information, wherein the storage mechanism comprises a directory service. The name service also has a data store interface for interacting with the directory service, wherein such interaction comprises the use of protocol compliant with LDAP version 2. In an alternative embodiment such interaction consists essentially of the use of protocol compliant with LDAP version 2. And in a third embodiment, such interaction consists of the use of protocol compliant with LDAP version 2.
Another variation calls for a computer system arranged to implement at least one storage mechanism for a name service, where the name service being arranged to store persistent information. The computer system comprises a processor, a data store interface for interacting with the storage mechanism, and at least one storage mechanism arranged to store the persistent information. The storage mechanism is in the form of a directory service encapsulated in the data store interface.
Finally, this aspect may be expressed as a computer program product for implementing a name service having at least one storage mechanism. The computer program product includes computer code that creates a name service arranged to store persistent information, computer code that creates a data store interface for interacting with the storage mechanism, and computer code that creates the storage mechanism which is arranged to store the persistent information. In this embodiment, the storage mechanism comprises a directory service and is encapsulated in the data store interface. The computer program product incorporating the above computer codes also includes a computer readable medium that stores the computer codes. In a preferred version of this computer program product, the interaction between the data store interface and the storage mechanism comprises the use of protocol compliant with LDAP version 2 and the directory service is compliant with LDAP version 2. An alternative embodiment of the computer program product specifies that the computer readable medium is a code representation embodied in a carrier wave.